Even if the times used by all OPC servers were perfectly synchronized, one needs to consider how the OPC subscriptions are realized and what effect it has on the time monotony. In OPC, data change or event delivery is not usually immediate, for performance (throughput) reasons. Notifications are transferred in larger chunks, and only after certain time elapses, so that they can accumulate.

Let’s have a look at following situation where we have two subscription, using different notification rates:

The red circles denote times when new source data appear. The blue squares denote times when the server delivers notifications to the client.

In this case, following occurrences happen in real time sequence:

1. At time T2, the new source data appear on Subscription2 (which has slower notification rate).
2. At time T1, the new source data appear on Subscription1 (which has faster notification rate).
3. At time t1, the data from Subscription1, carrying a T1 timestamp, are delivered to the client.
4. At time t2, the data from Subscription2, carrying a T2 timestamp, are delivered to the client.

As a result, the event that has appeared later (on T1) is delivered to the client earlier than the event that has appeared sooner (on T2). If the StreamInsight application wanted to use the timestamps of the source data, the time monotony requirement would be broken.

In addition, even with a single subscription, the OPC “Classic” server may send data with timestamps in reversed time order, albeit that would be quite rare and probably an indication of a buggy server.